👷 ci: add merge_group trigger ahead of enabling the merge queue - #202
Merged
Conversation
The merge queue tests each queued pull request on a temporary
`gh-readonly-queue/...` ref and reports the result against the
`merge_group` event. A required status check whose workflow does not
listen for that event therefore never reports on a queued pull request,
and the queue waits indefinitely -- enabling the queue before this
trigger exists deadlocks every merge. `build-and-test` is the only
required check in this repository, so it is the one that matters.
This commit is inert on its own. With the queue disabled GitHub emits no
merge_group events, so no new runs are produced and nothing about the
current push and pull_request behaviour changes. That is the intended
sequencing: the trigger has to be on main before the setting is flipped,
never after.
The existing concurrency group needed checking rather than assuming. It
keys on `ci-${{ github.ref }}` with cancel-in-progress enabled, and a
queued run's ref is the unique per-pull-request readonly-queue ref, so
each queued run lands in its own concurrency group and cannot cancel a
sibling. No change required.
Enabling the queue itself is a repository setting and is deliberately
left to a maintainer.
cwest
force-pushed
the
topic/ci-merge-group
branch
from
July 26, 2026 14:00
de621fc to
9d91294
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The merge queue tests each queued PR on a temporary
gh-readonly-queue/...ref and reports results against themerge_groupevent. A required check whose workflow doesn't listen for that event never reports — so the queue waits forever and every merge deadlocks.build-and-testis the only required check here, soci.ymlis the one that matters.This is intentionally inert
With the queue disabled, GitHub emits no
merge_groupevents. No new runs, no change to existingpush/pull_requestbehaviour.That's the point — the trigger must be on
mainbefore the setting is flipped, never after. This PR is step 1 of 2.Concurrency: checked, not assumed
ci.ymlusesconcurrency: ci-${{ github.ref }}withcancel-in-progress: true, which is exactly the shape that can sabotage a queue if runs share a group.They don't. A queued run's
github.refis the unique per-PR readonly-queue ref (refs/heads/gh-readonly-queue/main/pr-N-<sha>), so each lands in its own concurrency group and cannot cancel a sibling. No change needed.Not included
Enabling the queue is a repository setting and is left to you — I don't change repo settings without explicit approval.
Once this is on
main, the ordering constraint is satisfied and the queue is safe to turn on.Verified clean under
zizmorwith online audits enabled, andmake lint-configspasses.